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(57) A method and apparatus for Disk Scheduling 
and Non-Linear Video Editing includes the processing 
of sinnultaneous read requests and write requests of a 
storage device in the presence of realtime requirements 
that are associated with these requests. The metho(d in- 
cludes constructing a storage device data structure with 
a plurality of partitions that correspond to a plurality of 
seek paths, with the storage device data structure stor- 
ing both read and write requests. The read requests are 
assigned read request deadlines based at least in part 
on a user desired response time for handling the read 
requests. The write requests are assigned write request 
deadlines based at least in part on the capacity of the 
write buffer. The write buffer stores data associated with 
write requests until the data is written to the storage de- 
vice. The read and write requests are placed within the 
storage device data structure based at least in part on 
the read request deadlines and write request deadlines, 
such that a optimal seek path is maintained for each of 
the plurality of partitions while minimizing violations of 
the read request deadlines and write request deadlines. 
The invention may be applicable for use as a storage 
device access scheduler of the supporting video on de- 
mand and non-linear editing of a storage device in the 
presence of real time requirements that are associated 
with the read requests and write requests of video on 
demand and non-linear editing. 
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Description 

BACKGROUND OF THE INVENTION 

s 1 ■ Field of the Invention 

[0001] The present invention relates to a new disk scheduling algorithm for supporting simultaneous read and write 
requests that are made by a user in the presence of real-time requirements and high bandwidth demands. 

10 2. Description of Background Art 

[0002] During the past few years, systems that enable a user to manipulate the content of a video database have 
gained increase popularity. These systems, referred to as non-linear editing systems, are widely applied in the enter- 
tainment industry where the underlying storage server must be able to concurrently record a live broadcast feed, modify 
15 pre-recorded data, and broadcast an authored presentation. While most of these non-linear editing systems are cur- 
rently analog, products providing support for digital editing continue to emerge. 

[0003] An important component of a digital editing system is the multimedia storage server that can display and 
record digital video. The design complexity of such a storage server arises because of the wide range of activities in 
which clients and applications may participate. For instance, consider an editing system employed by a TV news 

20 organization. While the live telecast of the Olympic games is in progress, editors have to record and monitor the program 
in order to identify the highlights that can be used in later broadcasts, and editors at different sites may be concurrently 
performing editing operations on different clips. For example, any one editing station may be responsible for the swim- 
ming events and another station for gymnastics. Thus, the storage server would be responsible for writing the digital 
data which is provided from a camera, reading on-disk data for reviewing by the editors, updating on-disk data as a 

25 result of an editing operation such as a cut-and-paste, and reading on-disk data for broadcasting or video viewing. 
[0004] Due to these real-time demands of video viewing, requests to read stored data have to be fulfilled within 
certain deadlines, otherwise they are considered lost. However, since data that is to be written onto a storage disk is 
originally stored in main memory buffers (or write buffers), write requests can be postponed until critical read requests 
are processed. But, write requests still have to be processed within a reasonable time and without the possibility of 

30 indefinite postponement. This is a result of the physical constraint of the main memory buffers size. 

[0005] In view of the foregoing, it is desirable to minimize the amount of disk reads that do not meet their presentation 
deadlines, and to avoid indefinite postponement and large buffer sizes in the case of disk writes. Furthermore, since 
seek time is the most time consuming part of retrieving a page from a disk, it is desirable to improve the throughput of 
the storage server by enhancing the utilization of available disk bandwidth. 

35 

SUMMARY OF THE INVENTION 

[0006] The present invention provides an apparatus, article of manufacture and method of supporting the processing 

of simultaneous read requests and write requests of a storage device in the presence of real-time requirements that 
40 are associated with these requests. The method includes constructing a storage device data structure with a plurality 
of partitions that correspond to a plurality of seek paths, with the storage device data structure storing both read and 
write requests. The read requests are assigned read request deadlines based at least in part on a user-desired response 
time for handling the read request. The write requests are assigned write request deadlines based at least in part on 
the capacity of the write buffer. The write buffer stores data associated with write requests until the data is written to 
45 the storage device. The read and write requests are placed within the storage device data structure such that an optimal 
seek path is maintained for each of the plurality of partitions while minimizing violations of the read and write request 
deadlines. 

[0007] Further scope of applicability of the present invention will become apparent from the detailed description given 
herein. However, it should be understood that the detailed description and specific examples, while indicating preferred 
50 embodiments of the invention, are given by way illustration only since various changes and modifications within the 
spirit and scope of the invention will become apparent to those skilled in the art from this detailed description. 

BRIEF DESCRIPTION OF THE DRAWINGS 

55 [0008] The present invention will become more fully understood from the detailed description given herein below 
and the accompanying drawings which are given by way of illustration only and thus are not limited on the present 
invention, and wherein: 
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Figure 1 is the video server architecture used in conjunction with the present invention; 
Figure 2 is a data flow diagram according to the present invention; 

Figure 3 is a flow chart illustrating the disk scheduling process of the present invention that supports simultaneous 
disk read and write requests; and 
s Figure 4 is an enlarged view of the multiple partition queue. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT(S) 

[0009] The present invention relates to disk scheduling for simultaneous read and write requests in the presence of 
10 real-time requirements of video viewing and editing applications. Both of these applications has its own system re- 
quirements. Our focus here is on the disk scheduling requirements. For example, from the disk's point of view, video- 
on-demand applications issue read-only requests to the disk, while video editing applications issue both read and write 
requests. Moreover, some applications may issue read and/or write requests that may or may not have real-time dead- 
lines. 

15 

The Nature of Deadlines 

[0010] For video-on-demand, each read request typically has to be fulfilled within a given deadline, but some appli- 
cations may allow a portion of the read or write requests to be lost by the system, i.e., the requests are not sen/iced 
20 or fulfilled by the disk. For example, some frames can be lost during video viewing due to congestion in the disk. 

[0011] More formally, from a disk scheduling point of view, disk read and write requests can be classified as belonging 
toone of four categories, where each category has different requirements and is useful for a certain class of applications. 
These categories are: 

25 1. dl requests: these are read or write requests that have deadlines and the request may be lost in the case of 

contention. Read and write requests of this category are referred to as R^i and W^i requests, respectively. 
2. dn requests: these are read or write requests that have deadlines and the requests may not be lost (non lossy) 
regardless of the contention in the system. Read and write requests of this category are referred to as Fl^p and 
Wjjn requests, respectively. 

30 3. nl requests: these are read or write requests that have no deadlines and the request may be lost in case of 

contention. Read and write requests of this category are referred to as R^i and W^i requests, respectively. 
4. nn requests: these are read or write requests that have no deadlines and the requests may not be lost (non 
lossy) regardless of the contention in the system. Read and write requests of this category are referred to as F^^ 
and W^n requests, respectively. 

35 

[0012] Different disk scheduling procedures need to be designed for each of these request categories. Requests 
belonging to the nl category (whether W^-i or R^-,), can always be delayed until processed because there are no dead- 
lines. Therefore, the system should avoid losing them, as they can afford to wait until serviced. As a result, W^i and 
Rpi requests are treated as W^^ and R^p, requests, respectively, and they will never be lost. For this reason, the sched- 
40 uling techniques for only the dl, dn and nn categories are expressly considered herein. The system allows simultaneous 
support of video editing and video-on-demand applications including R^, requests, which comprise most of the video- 
on-demand accesses, and R^^ and W^^ requests, which comprise most of the editing-oriented accesses. It should 
also be understood that this invention may be easily extended to handle R^j^, W^i, and W^^ requests as well. 

45 Example of Video Server Architecture 

[001 3] The present invention may be practiced on a video server architecture that was originally proposed in "A File 
System for Continuous Media" at The Fifth International Workshop on Multi-Media Communication, pgs. 341 -346, May 
1994, which is herein incorporated by reference. The main components of this architecture are shown in Figure 1 . 
50 [001 4] The video server 1 0 supports MPEG-encoded (compressed) video streams. Each stream is broken into fixed- 
length pieces, termed media segment file (MSF) blocks. The MSF blocks for a given video stream are stored distrib- 
utively throughout the whole file system. The file system has multiple disk storage servers, where each storage server 
is termed a Media Segment File Server (MSFS) 12. 

[0015] The MSFS 12 stores MSF blocks that belong to a variety of video streams. In order to retrieve the video in 
55 the correct order, a Sequence Control Broker (SCB) 14 stores an ordered list of pointers to all the MSF blocks of a 
video stream. The SCB 1 4 acts on behalf of users to maintain a video playback stream . Each SCB 1 4 can sim ultaneously 
support more than one user terminal 16, (e.g., 64 users). The number of user terminals 16 connected to one SCB 14 
is predetermined so that the overall system guarantees continuous video playback for all the users. 
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[0016] In the initialization of a video playback session, the SCB 14 fetches the list of pointers for a requested video. 
During the playback, the SCB 14 sends a read request to the MSFS 12 on behalf of the user such that uninterrupted 
service is guaranteed. The SCB 1 4 is also responsible for handling virtual video cassette recorder (VCR) requests, e. 
g., fast forwarding and rewinding. 
s [0017] The SCB 14 and the MSFS 12 are built into one main building block, termed a video Processing Unit (PU) 
18. In one video server, there can be multiple PU units (e.g., 15 units). Each SCB 14 can directly access the data that 
locally resides in its corresponding MSFS 12. However, MSF blocks are stored across other MSFs 12, and the SCB 
1 4 needs to access the MSFs 1 2 of the other processing units 1 8. 

[0018] In order for the PUs 18 to communicate, they are all connected to an asyncronous transfer mode (ATM) switch 
10 20. An SCB 1 4 may use the ATM switch 20 to retrieve a MSF block that is distributed across the MSFs 12 which reside 
in multiple PUs 18. The ATM switch 20 provides a mesh network that guarantees a connection from each SCB 14 in 

the system to all of the MSFSs 1 2. 

[0019] The SCBs 14 are also connected to an external network 22 that connects the VideoServer 10 to the end users 
16. Users 16 are connected to the external network 22 by using set-top boxes that have the following functions: decoding 
15 MPEG-encoded video data, providing user interface for virtual VCR requests and communicating with the SCBs 14. 

A Review of Disk Scheduling Concepts 

[0020] In video-on-demand applications, read requests are the result of users demanding to view a certain movie or 
20 a video clip at a certain time. Once admitted to the system, the user is guaranteed a certain Quality Of Service (COS). 
This is expressed in terms of viewing a continuous stream of frames where the rate of frame loss is very low and is 
not noticed by the viewer. Frame losses are possible due to many reasons. Of specific concern are the losses due to 
congestion of the disk in the MSFSs 1 2. 

[0021] Each read request to the disk has a real-time deadline. The MSFS 12 decides whether the disk can fulfill the 
25 request within this deadline. Based on this decision, the read request is either accepted or rejected. In the latter case, 
the page corresponding to the rejected read request is considered lost. 

[0022] Seek time is the most time-consuming part of disk retrieval. One purpose of disk scheduling algorithms is to 
reduce this seek time. This can be achieved by queuing and ordering the disk access requests so that seek time is 
minimized. 

30 [0023] Process SCAN is one of the traditional disk scheduling algorithms that attempts to minimize seek time. (See, 
Operating System Concepts, 4th Edition. A. Silberschatz and RB. Galvin. Addison-Wesley, 1994.) In SCAN, the disk 
head moves in one direction (either inward or outward) and services the disk requests whose cylinder falls where the 
disk head is currently positioned. Once the disk head reaches the high cylinder position, it reverses direction and 
services the disk requests which happen to lie along the new path. If real-time requirements are involved, SCAN is 

35 modified to meet the real-time considerations. 

[0024] Process SCAN-RT (SCAN with Real Time considerations) is a modified version of SCAN. SCAN-RT services 
disk requests in SCAN order, and inserts new requests in SCAN order provided that the real-time requirements of the 
disk requests already existing in the queue are not violated by the insertion. If the insertion of the new request in SCAN 
order causes other requests already present in the disk queue to miss their deadlines, then the new request is inserted 

40 at the end of the queue. At this time, it is determined if the newly inserted disk request can be serviced in time to meet 
its own deadline. If the request cannot be inserted to meet its own deadline, the request is discarded and considered lost. 
[0025] Minimizing seek time alone may not be sufficient. In some instances, the user must be guaranteed that the 
data will be delivered at the specified time, with losses low enough that dropped frames will not be noticeable. Although 
delays in data delivery may occur for various reasons, there are times in which a disk scheduling algorithm must actively 

45 participate in maintaining the guaranteed QOS. 

[0026] An Earliest-Deadline-First (EDF) algorithm addresses this issue without trying to optimize the disk bandwidth 
utilization, thus limiting the capacity of the server. Process SCAN-EDF is another modified version of SCAN that uses 
an EDF process. As with the SCAN-RT algorithm, the SCAN-EDF algorithm attempts to order real-time constraints 
without unduly affecting bandwidth utilization. SCAN-EDF processes requests according to their deadlines, just like 

50 EDF and requests with the same deadlines are serviced in SCAN order. If all of the requests have distinct deadlines, 
SCAN-EDF degenerates to EDF. On the other hand, if all the requests have the same deadline, SCAN-EDF behaves 
similarly to SCAN. 

[0027] While it has been recognized that a real-time scheduling algorithm must be used to process read requests, 

a scheduling algorithm has not heretofore been developed to successfully handle disk write requests in conjunction 
55 with disk read requests. The lack of an application-specified deadline precludes the use of a real-time scheduling 
algorithm for writes. One possible solution which has been presented is to maintain two separate queues, one queue 
for reads and a second queue for writes. The read requests are scheduled using any of the above algorithms, e.g., 
SCAN-EDF, SCAN-RT, etc. Each write request is associated with a fixed time-out. A write is issued to the disk either 
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when (1 ) it does not violate the deadlines of the pending write requests; (2) the write buffer is full (or almost full); or (3) 

a fixed write time-out expires. 

[0028] This solution has been found to have several drawbacks. First, batching a large number of writes to increase 
the disk bandwidth utilization (by reducing seek time) may lead to either an increased likelihood of the system violating 
s the deadline of newly arrived read requests or stan/ation of the write requests. Also, interrupting the SCAN order of 
currently existing reads to schedule writes may increase the average seek time and lower disk utilization. This increases 
the overall delay of read requests at the server, leading to a reduction in QOS, as observed by the application. Therefore, 
the present invention presents a technique that treats read and write requests in a homogenous manner, and assigns 
a deadline to the write requests in order to maintain a single queue. 

10 

Homogenous Handling of Read and Write Requests 

[0029] Figure 2 presents the storage device access scheduler of the present invention that receives and processes 
both video-on-demand 24 and non-linear editing requests 26. As can be seen, the video-on-demand requests 24 are 
15 only read requests while the non-linear editing requests comprise both read and write requests 30. The data that are 
to be written to the disk 32 as part of an editing operation are initially stored in a write buffer 34 until the corresponding 
request is processed and the data are transferred to the disk 36. 

[0030] The read requests 28 and read and combined write requests 30 are provided to a read request deadline 
assigner 38 and to a write request deadline generator 40. Each read request 42 is assigned a deadline 44 by the read 
20 request deadline assigner 38 and each write request 46 is assigned a deadline by the write request deadline generator 

40. These read and write requests are then inserted into a memory 51 that is a subdivided data structure (or multiple 
partition queue) 52, by the disk queue organizer 50, with each partition corresponding to an optimal seek path. In this 
way, violations of both read and write request deadlines are minimized. 

[0031] As can be seen in Figure 3, the multiple partitions (56,57,58,59) of the multiple partitioned queue 52 are 

25 sequentially arranged and numbered such that disk requests in partition 1 (56) are processed by the disk server before 
the disks requests in partition N (59). Thus, requests in partition N will experience the longest delay in the system. With 
this multiple partition structure and processing technique, two issues need to be addressed. First, how and when are 
new partitions created or formed, and second, in which partition is an arriving disk read or write request placed. 
[0032] The disk read and write requests are inserted into the appropriate partitions of the queue according to various 

30 rules that are subsequently described in greater detail. However, it is important to mention that based on the nature of 
the read or write request, the partitions can be examined in front-to-back or back-to-front order. Front-to-back order 
means that when a request arrives the system starts by examining partition 1, then partition 2, etc., until it finds the 
first partition that satisfies the insertion condition. On the other hand, back-to-front order implies that the system ex- 
amines the partitions in the reverse order, i.e., starting with partition N, followed by partition N - 1 , etc. 

35 [0033] Figure 4 shows an overview of the process of the present invention. Initially, a multiple partition queue is 
constructed with each partition corresponding to one scan or seek path of the storage device or disk (54). The queue 
partitions hold requests independently of whether the request is a read or write and places all requests in scan order 
After the multiple partition queue is constructed (54), an initial determination is made as to whether the received request 
is a read or write request (60). In the event the request is a read request, the read request deadline assigner assigns 

40 a deadi ine (62) . Th is is f ol lowed by the data storage organizer inserting the read request based on the assigned deadline 
and scan order (64). Both the assignment of the deadline (62) and the insertion procedure (64) will be subsequently 
described in further detail. 

[0034] In the event the request is a write request, the data corresponding to the request is inserted into the write 
buffer at the next available slot (66). Following the insertion of the data into the write buffer (66), the calculated value 

45 of the arrival rate of disk write requests (X^) is updated. is an estimate of the time in which the write buffer will be 
filled, and is used to compute the deadlines for the write requests. Therefore, the accuracy of is important to the 
performance of the system. It is possible to assume that the value of is constant during disk server execution, and 
hence is given a priori. However, rf is overestimated, then this may result in forming over-restricted deadlines that 
do not reflect reality. As a result, more read request losses may be experienced. On the other hand, when Aw is 

50 underestimated, the system may not take into consideration the congestion in the write buffer. This is because an 
insufficient number of write requests may be scheduled when their deadlines are overly relaxed. Therefore, the write 
buffer may fill quickly and bursts of write requests have to occur, thus forcing many consecutive read requests to be lost. 
[0035] Once the calculated value of has been updated (68), a determination is made whether >^ has changed 
significantly and thus requires updating prior to calculation of a deadline (70). In the event the disk request has changed 

55 significantly, the deadlines for write requests already in the disk queue are recomputed and the queue is reorganized 
(72). However, if X^ has not changed significantly, no recomputing of deadlines is performed nor is the queue reorgan- 
ized. 

[0036] Once the actions or inactions relating to 7^ have been completed, the deadline for the received write request 
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is calculated (74) and the request is inserted into the disk queue based upon scan order (76). Based upon this deadline, 
it can be seen that both read and write requests can be processed and subsequently inserted into the disk queue for 
processing such that an optinnal seek path is maintained for each of the plurality of partitions while minimizing violations 
of both read and write request deadlines. 
s [0037] With this overview of the process of the present invention in mind, greater detail will be subsequently provided 
for assignment and calculation of both read and write deadlines, insertion of requests, processing requests, subsequent 
dynamic computations involving X^„ and handling the variations in Xyj^. 

Deadline Computation For Write Requests 

10 

[0038] In a video editing session, write requests are modeled as belonging to the W^^ category. W^^i write requests 
have the following characteristics: 

1 . Any page to be written to the disk is already pre-stored in a main-memory buffer pool. 
15 2. A Wpj^ write request has no real-time deadline. Therefore, it can afford longer delays than read requests. 

3. Although it does not have a deadline, a W^^ write request cannot be kept indefinitely in main-memory buffers 
due to the risk of loss in case of a system crash or power failure. It has to be fulfilled sometime in the future to 
avoid the write buffer pool becoming to full. The longest possible duration that a write request can wait in the buffer 
before being forcibly flushed into the disk (Tw^^gx) ^ tunable system parameter and is computed based on the value 

20 of the mean time between failure. 

4. A W^n write request cannot be lost due to system load, etc. AWi write request has to be fulfilled by the system 
at some point in time. 

5. Based on the system load, the write buffer pool can become full. At this point, some pending W^^^ write requests 
have to be flushed to disk, thereby releasing buffer space for newly arriving write requests. 

25 

[0039] A deadline needs to be imposed on all writes. While the deadlines of W^j^ and W^i requests are specified by 
the application, the deadline associated with W^^ requests has to be artificially computed by the storage server based 
on the number of available buffers and the expected arrival rate of write requests (X^). 

[0040] In order to compute the artificial deadline of a W^^ write request, the following parameters are utilized: 

30 

1 . Ng is the size, in bytes, of the write buffer pool. Note that a larger write buffer is expected to reduce the require- 
ments imposed on the system due to write requests. 

2. Pw is the size, in bytes, of a write page. Note that with a value for Nb and p^, we can compute the number of 
write pages that the write buffer pool can accommodate, which will be denoted by N^,,. 

35 3. Wf^aj( is the maximum time that the system allows for a write request to wait in the buffer before being forcibly 

flushed to the disk. 

4. As previously discussed, is the arrival rate of disk requests to the system and is dynamically measured by 
the system based upon a measurement of the inter-arrival time between write requests or a period of time. Alter- 
natively, may be considered to be constant with a value that is based on the ratio of the number of editors to 
40 the number of viewers and for editors, the ratio of the number of read requests to write requests (i.e., ((#of editors) 

/(total # of users))* ((# of write request for editors)/(total # of requests for editors))). 

[0041] Assuming that at time t, a user requests that a page, say Pj be written into the disk. It is desirable to assign 
a deadline for page Pj such that it has to be written into the disk before the deadline. We compute the deadline of a 
45 write request in the following way. Let n^(t) be the number of write requests that exist in the buffer at time t, and 

npCt) be the number of free buffer slots in the buffer pool at time t. Then, 

np(t) = N^-n^(t). (1) 

50 

In the worst case scenario, because of the Rj read requests, no pages will be written from the write buffer to the disk, 
and at the same time, new requests will continue to arrive to the write buffer pool at a rate of X^. As a result, at the 
time the write page Pj arrives to the write buffer pool (due to a new write request), an estimate of the time until the write 
buffer pool is full (d(t)), can be computed as follows (worst case scenario): 

55 
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Qf(0=r + ^. (2) 

Notice that d(t) is in fact the deadline of any page in the write buffer pool at time t, i.e., a global deadline for all of the 
pages currently in the write buffer. As a result, if any of these pages are physically written into the disk by the scheduling 
algorithm, the value of d(t) is relaxed in the foliowing manner. 

[0042] When a portion of pj is physically written into the disk, it frees one buffer slot in the buffer pool. As a result, 
the deadline d(t) for all of the pages in the buffer pool is relaxed, i.e., there is now more time until the buffer becomes full. 
Therefore, d(t) is relaxed as follows. Let to be the last time d(t) was modified. Then, 

d{t)^t-to+d{to) + j-. (3) 

This is also consistent with the above formulation for d(t), i.e., 

d(0 - t-t, + d%) + -1 (4) 



t ^ (6) 



t - (7) 



[0043] Notice that since to is the last time any change in the buffer pool is made, np (t) = np (X^)+ 1 is the new amount 
of space after the write page has been physically written to the disk. When a write page request arrives, the corre- 
sponding page, say Pj, is placed in the write buffer pool. In order to insert a write request into the disk queue, a deadline, 
say d^ (t), must be assigned for Pj that corresponds to global deadline d(t) of the write buffer pool, i.e., d^ (t) <r- d (t). 
Finally P| and its deadline d^(t) are inserted into the disk queue. As can be appreciated; the write request is inserted 
into the scan order in a manner similar to the way that the SCAN-RT scheduling algorithm handles read requests. The 
mechanism by which this is achieved, and the corresponding interplay between read and write requests, is subsequently 
described. 

Deadline Computation For Read Requests 

[0044] Two types of read requests must be supported, the R^i and read request. The deadline of an R^| request 
is determined by the video server and is therefore provided as a constant. For example, in order to play a video-on- 
demand application, the viewer has to see 30 frames per second. This translates to a frame every 33 milliseconds. 
Assuming that a frame corresponds to a read request, then the deadline for the read request is 33 milliseconds. 
[0045] Therefore, the following description is focused on the R^^ read request. 

[0046] The R^^ category of read requests is useful forvideo editing applications. R^^ read requests have the following 
characteristics. 
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1. An R^n read request has no real-time deadline. Therefore, this request can afford longer delays than other 

requests. 

2. Although it does not have a real-time deadline, a R^p read request still cannot wait indefinitely. It has to be 
fulfilled sometime in the future, with the longest possible duration for this request to be held provided as a system 
parameter which is tunable. For example, the system administrator may decide that the maximum amount of waiting 
time for an editors read request is 0.5 seconds. In this instance, Tr^ax '® ^-^ seconds (i.e., the deadline for 

Rp^ requests is 0.5 seconds). 

[0047] In order to determine an a/t/f/c/a/ deadline for R^^, the following parameters are utilized: 

1 . Tr^^ (as previously indicated) is the maximum time that the system allows a R^^ request to wait before being 
forcibly serviced by the disk. 

2. Xf. is the arrival rate of R^^ requests to the system. 

[0048] For W^^ write requests, because of the lack of a deadline, they are considered as a lower priority request 

than the R^i read request. Similarly, because of the lack of a deadline, R^^ read requests are considered as having a 
lower priority than R^, read requests. However, in contrast to write requests, since R^^ read requests have no buffer 
problems (as long as there is room for the page to be read). We can also consider R^.^ requests as having less priority 
than write requests. Therefore, R^^ read requests are given the least priority in terms of scheduling. 
[0049] The time Tr^^ is observed as the arf/f/c/a/ deadline for R^^, read requests. In other words, if an Rp^ read 
request, say rj, waits in the system for more than Tr^gx ^i"^® units, then rj has to be forcibly processed by the system 
regardless of the losses incurred by this read. 

Inserting a W m m Write Request 

[0050] As previously indicated, once a write request, say Wj, arrives to the disk to be served, the corresponding page 
is inserted into the write buffer pool at the next available buffer slot, and the write request is assigned a artificial deadline 
using the previously described technique. Once the deadline has been assigned to the write request, the write request 
is inserted into the disk queue. 

[0051] In order to insert the write request Wj into the disk queue, the following steps are performed. In addition to the 
following description, pseudo code for inserting VJ^^ write requests can be found in Appendix A. First, the determination 
is made as to which partition of the disk queue the write request Wj gets inserted, and secondly once the partition is 
determined, the attempt is made to insert the write request Wj in the appropriate scanned order. 
[0052] The first step can be achieved by traversing the queue partitions either in a front to back or in a back to front 
order. For example, in the back to front order, the algorithm starts from the partition (the farthest from the disk 
server), and attempts to insert Wj into in scan order. If the deadline of Wj is violated, then an attempt is made to insert 
Wj Into partitions Pp.-,, Pn.2, etc., until the algorithm finds the first partition Pj such that Wj can be inserted into Pj in scan 
order without having Wj's deadline violated. It is also possible that all partitions, including partition P^, violate the deadline 
for Wj. This is an extreme case and is not expected to happen. However, the action taken in the event of this extreme 
case will be subscribed below (see Case 5). 

[0053] In the second step, the scheduling algorithm attempts to insert the new write request Wj in its scan order in 
the current partition, say Pj. During this insertion process, five possible cases might arise: 

Case 1 : The deadlines of the pending read and write requests (including the new write request) are not violated by 

this insertion. 

Case 2: The deadline of the new write request will not be violated if it is inserted in scan order, but upon insertion, 

the deadline of some other R^,^ read requests will be violated. 
Case 3: The deadline of the new write request will not be violated if it is inserted in scan order, but upon insertion. 

the deadline of some other R^j read request will be violated. 
Case 4: The deadline of the new write request will not be violated if it is inserted in scan order, but upon insertion, 

the deadline of some other write request will be violated. 
Case 5: The deadline of the new write request will be violated (arises when all of the partitions, including P|, violate 

the deadline of the new write request). 

[0054] Case 1 is the simplest to handle and represents the best possible scenario. If the scheduling algorithm finds 
that it is possible to insert the write request Wj into the queue partition Pj (resulting from traversing the queue partitions 
in the back to front order) without violating any of the deadlines of the read and write requests that already exist in the 
queue, as well as the deadline of the new write request Wj, then Wj will be inserted in the disk queue in its scan order. 



8 



EP0 936 615 A2 



[0055] In Case 2, the deadline of the new write request is not violated when it gets inserted in its scan order, but 
upon inserting it. the deadline of some other R^n read request is violated. Assume that the violated R^^^ request r; is in 
partition P|. In this case, an attempt is made to insert rj into P|.-|. If this attempt is successful, without violating any 
deadlines of other requests, then both of the insertions of Wj and r■^ take place. Otherwise, rj is left in its current location 
s in P even though r's deadline is violated. This is because write requests have a higher priority than R^^ read 
requests. 

[0056] In Case 3, the deadline of the new write request (Wj) is not violated when it gets inserted in the scan order. 
But upon inserting it, the deadline of some other R^n read request, say rj is violated (note that the algorithm can be 
repeated at this step if the deadline of more than one R^i read request is violated). The algorithm attempts to avoid 

10 losing fj. If Wj can be placed at the next partition, in scan order, without getting its own deadline violated, then Wj is 
placed in this next partition. This may save rj from being lost, however if moving W| to the next partition will violate Wj's 
deadline, then Wj is not moved from its current partition and some Rj requests are identified to pre-empt. 
[0057] Any R^n read requests that are ahead of rj in the queue that can be pre-emptiedfrom their location to a partition 
that is past the location of rj are sought. If such an Rf,^ read request Is found, and moving this read request results in 

15 saving Rj, then the located request is moved from its location to a location past rj. Otherwise, Wj is inserted into its 
current location and rj is lost. 

[0058] Cases 1-3 constitute the typical scenarios during regular system operation. On the other hand, cases 4 and 
5 are extreme cases that happen only when the rate of write requests exceeds the predetermined upper limit at system 
configuration time. For example, if the system load changes, e.g., (# of editors )/(total number of users) changes, the 
20 pre-computed value of is affected and the resulting system performance is poor (cases 4 & 5) and must be 

recalculated. 

[0059] It should be notedthat when the frequency of cases 4 and 5 becomes significant, this Indicates that the request 
pattern has changed significantly, and that it is time to re-evaluate system parameters, e.g., expanding the size of the 
write buffer pool. However, while this indicates it is time to re-evaluate the system parameters, cases 4 and 5 must be 
25 handled. 

[0060] In Case 4, the new write request violates the deadline of another write request that already exists in the disk 
queue. In this case, the algorithm searches for any R^^ request to move to a farther location. Since W^n requests have 
higher priority over R^n requests, a violated R^^ request gets pre-emptiedfrom the location and is movedtothe partitions 
that are next to their current partitions. If none is found, or if moving the R^p requests will not save the write requests 
30 from having their deadlines violated, then all of the write requests that had their deadlines violated are moved to par- 
titions that are ahead in the disk queue, or to the head or the disk queue, if no such partitions exist. As a result of this 
action, R^| read requests, whose deadlines become violated, are considered lost. As previously indicated. Case 4 (new 
write requests violating the deadlines of other write requests) represents an extreme situation which indicates that the 
write buffer pool is getting congested and that the system is getting overloaded. This situation should be avoided by 
35 the admission control algorithm of the video server 

[0061] In Case 5, the deadline of the new write request will be violated if it is inserted in its scan order We recall that 
the deadline of a write request is computed based on the time by which the write buffer will get full. As a result, the 
write request cannot afford having its deadline violated, as it will result in a buffer overflow and possible loss of write 
requests. Since Wp^ pages cannot be lost (by definition), the new write request must be scheduled without violating 
40 its deadline. This is achieved as follows. The new write request is placed at a partition that is ahead in the disk queue, 
or at the head of the queue, if no such partition exists. The read request whose deadline has become violated is 
considered lost, while the write request whose deadline becomes violated is treated as in case 4, i.e., is moved forward 
in the queue to another partition or, at worst, to the head of queue, along with the new write request. 
[0062] In both cases 4 and 5, the write requests that are moved to the head of the queue are ordered among them- 
es selves in scan order. Notice that since we are storing absolute deadlines for both read and write requests, upon insertion 
of the new request, we do not need to update the deadlines of these requests that are past the new request in SCAN 
order. 

Processing a W » » Write Request 

50 ~ 

[0063] In all of the above five cases, once a write page is inserted into the disk queue, it is guaranteed that it will be 
written physically into the disk, i.e., it does not get deleted from the disk queue. 

[0064] As previously discussed, writing a page into the disk will result in free buffer space (a space that is occupied 
by the write page). Therefore, once a page is written into the disk, we can relax the deadline of all of the pages in the 
55 write buffer pool, as well as the deadline of the write pages in the disk queue. 

[0065] We relax the deadline of the pages in the write buffer pool by modifying the global variable d(t), as previously 
discussed. Similarly, for the disk queue, upon writing a write page into the disk, we apply the following procedure. 
[0066] Let the current time be to- Initially, scan the disk queue and locate all of the write requests in the queue. 
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Secondly, for each write request Wj in the disk queue with priority (to), where (to) is the last time to (d^) is modified, 
set (t) to: 

5 dJt)^t-to + dJto) + Y- (8) 

The reason for this deadline relaxation is due to the requirements of the overall system, and hence reduces the number 
of read page losses. 

10 

Inserting and Processing R ^ i Read Requests 

[0067] The handling of an R^, read request is similar to what is being performed in the original SCAN-RT algorithm. 
In addition to the following description, pseudo code for inserting and processing R^j| read requests is contained in 
IS Appendix B. When a new R^i read request rj arrives in the disk queue, a determination is made as to which partition 
in the disk queue the read request be may inserted, and then the attempt is made to insert the read request in the 
correct SCAN order within the partition. 

[0068] Partitions are searched in a front-to-back or a back-to-front fashion, similar to what is described in the case 
of requests. The searching is performed until the first partition is identified such that the deadline for rj is not 
20 violated if rj is inserted into partition P| in scan order. If no such partition exists, then a search is conducted for any R^^ 

requests that can be moved from their location to another location to save rj. If such a R^^ request is found, then it is 
moved and jr is saved, hence it is inserted into its proper location in scan order. If no such R^^ request is found, then 
Tj is considered lost and is discarded. 

[0069] Assuming that a partition P| is found such that |r can be inserted without having rj's deadline violated, a check 
25 is made to see if the deadline of any of the requests in the queue is violated before inserting the request into that 
position. This applies to both read and write requests that already exist in the disk queue. If no deadline is violated, 
then the new R^ji read request gets inserted into the disk queue in its scan order. If one (or more) deadline(s) is (are) 
violated, then a check is made to determine if it will be possible for the new R^i read request to be moved to the next 
partition in the queue in the case of the front to back scan, or previous partition in the case of the back to front scan, 
30 or if any Rp^ requests can be pre-emptied from their location. In either case, if the deadline of the new R^i read request 
is not violated, then it is inserted in the proper location. Otherwise, the F\|| read request is considered lost and is not 
processed. 

[0070] It should be noted that one possible optimization scheme is to search for write requests in the queue that can 
afford to be repositioned at the end of the disk queue without encountering a deadline violation. This repositioning of 
35 a write request is performed only if it will result in accommodating the new read request into the read request's scan 
order and with its deadline met. 

Inserting a R ^ ^ Read Request 

40 [0071] Assume that a new R^^ read request, say fj, arrives to the system at time t, and that we want to insert r; into 
the disk queue. The deadline of is computed as t + Tr^^. Based on the deadline of rj, we determine the farthest partition 
Pk, such that inserting rj into p^ will not violate rj's deadline, and inserting jr into p^ + 1 will violate rj's deadline (i.e., p^ 
is the farthest possible location from rj without violating rj's deadline). It remains to be shown in which partition (P,... 

Pj^) rj is inserted. 

45 [0072] One possible option is to insert rj into partition P|^ and let it wait in the queue until it is served by the disk server 
However, this is a pessimistic solution and it does not attempt to serve rj earlier than its maximum deadline. A second 
solution is to attempt to schedule rj at an earlier partition p|^, as long as it does not violate any other request. IVIore 
specifically, rj is inserted into the disk queue in the following manner, as presented in Appendix C. 

50 1 . Examine the partitions of the disk queue from front-to-back (or alternately from back-to-front), i.e., starting from 

partition P-,, Pg, Pk, where K is selected such that rj can be safely inserted into p^ without violating its deadline, 
and violates its deadline if inserted into Pk + 1 • 

2. Let the current partition be Pj. If J = K, then insert rj into partition Pq such that Q is greater than or equal to K 
and the insertion of into Pq will not violate any W^n write requests. Discard any Rdl requests that have their dead- 

55 lines violated due to the insertion of R^^ into Pq. 

3. Else if rj can be inserted into Pj in scan order without causing any other request in the disk queue to violate the 
deadlines, then insert Tj in Pj. 

4. Else inserting rj into Pj in scan order will cause other requests in the disk queue to violate the deadlines, then 
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consider inserting Tj into Pj + 1 . 

[0073] It can be seen that it fj can be inserted into a partition Pj, where 0 < J, < K without violating the deadlines of 
any R^i or Wp^ requests, then rj can be inserted safely into Pj (step 3 above). However, if inserting r intp P will violate 

s the deadline of R^, or W^p requests, then consideration is given to insert in a farther partition than Pj (as long as J is 
strictly less than K). When J equals K, this means that Tj's deadline is about to be violated and hence has rjto be inserted 
into the disk queue as early as possible. There is a chance that inserting fj into will violate either R^n or request. 
The system discards any R^^^ request that will have their deadlines violated. However, the problem lies with W^p requests 
as they cannot be discarded. So, if inserting rj into P^ will result in violating the deadline of some W^^ requests, then 

10 rj is not inserted into Pk, and a farther partition PQWhere Q is greater than K, is found such that when inserting rj into 
Pq in scan order will violate the deadline of a W^^ request. In other words, because W^^ requests have higher priority 
than Rp^ requests, the system chooses to violate the deadline of ar R^^^ and not the deadline of a W„„ request. 

Estimating The Arrival Rate Of Disk Write Requests (K m) 
15 ~ 

[0074] As previously indicated, the accuracy of the value of the arrival rate of disk write requests (A.^) is critical to 
the performance of the system. I n order to enhance the system, both dynamic adjustment of and options for handling 
variations in 7^ are provided by the system. It should be noted that both dynamic adjustment and variation handling 
are enhancements that are orthogonal to each other and either one or both can be incorporated into the system. 

20 

Dynamically Computing X .., 

[0075] In order to dynamically compute the running average for is maintained. This accomplished by storing 
the most recent K values of the inter-arrival times of write requests, maintaining the running average of the most recent 
25 K inter-arrival times, and updating the running average each time a new write request arrives to the write buffer. 

[0076] A new value for is computed each time a new write request arrives to the write buffer. For purposes of the 
following description, let ^w-new ^^e value of that is computed after the arrival of the most recent write request, 
and Aw-current valuG of that is currently used by the system. Then, Aw.new computed with every arrival of 
a new write request, while A^.current '® compute the deadlines of the write request. 

30 



K-new (9) 



[0077] Let Iq, I 

-1' '-2' ' '(K-1) inter-arrival times between the consecutive K + 1 most recent write request. 

Then, the question that arises is when does >^vv-new become Xy^.^urrent' when is X^.^q^ used by the system to 
40 recompute the deadlines of the write request. A simple solution is to update the value of ^w-current ©ach time a new 
write request arrives in the write buffer. 

[0078] Once A^w-current assigned a new value, new deadlines will have to be computed for the write requests, and 
it is quite possible that the queue order will require modification based on the new deadlines. The problem with updating 
the value of A^/^.current ^^ch time a new request arrives is that this approach may induce significant system overhead 

45 although the change in A^^-current "^^y significant. On the other hand, it is advantageous for the value of A^y.^urrent 
to closely follow the real changes in a^, in order to be able to compute realistic deadlines for the write requests and 
avoid underestimating or overestimating their values to reflect the change of X^ only when the change is significant. 
[0079] There are several ways to detect significant changes in the value of 7^. One way is to adopt a thresholding 
scheme where ^w-current not updated with Xy^.^^^ unless the change in the running average of X^ becomes greater 

50 than a certain threshold I., i.e. when l^w-current " '^w-new ^- This thresholding mechanism is proposed in order to 
tolerate the temporary fluctuations in the value of X^. 

Handling The Variations In 

55 [0080] Once it is determined that 7^ has changed significantly from the running average, the system performs the 
following actions: 1) The write request deadlines are recomputed, and 2) if required, the order of the read and write 
requests in the disk queue are reorganized based on the new deadline calculation. 

[0081] Given the new value for Xyv-current' computing the new deadlines for the write requests that are in the disk 
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queue (step 1) is straight -forward. Simply, we followed the same steps as previously described in the section titled 

Deadline Computation for Write Requests. 

[0082] Step 2 can be handled in several ways based on whether the new is higher or lower than the previously 
estimated one. This is also reflected in the new priorities of the write request. There are two cases to consider. Case 
s 1 is when the write priority is relaxed, and Case 2 is when the write priority is tightened. Case 1 arises when 

- >-vv-new - while case 2 arises when >^w-new " ^w-current - ^- Several appropriate actions are possible in each of these 

cases that may affect the performance of the system. 

[0083] When the deadline of the write request is relaxed (case 1), two options are available. Option one involves 
migrating the write request that already exists inthedisl<queuetothe next scan order. The reason for this is to enhance 
10 the performance of the system by reducing the number of losses of Rji. This migration process can be achieved utilizing 
the following procedure. For each write request W^^^j that resides in the scan order of partition R which is the partition 
closest to the head of the disk queue, perform the following: 

1. Check to determine if a partition Pj + 1 exists in the disk queue. 
15 2. If Pj + 1 exists and if Wp^i can be inserted into Oj + 1 in scan order without violating W^^^i's relaxed deadline, 

then insert W^nj in the appropriate scan order position in Pj, otherwise keep W^^j in its current position in Pj. Note 

that the insertion of W^^j into Pj + 1 cannot violate any other requests in the queue since W„„j was already in the 

disk queue before migrating it. Therefore, with the existence of W^^^ii '"^ queue, all of the items that followed 

W^ni '"^ tl^® queue already have their deadline satisfied. 
20 3. If Pj + 1 does not exist (i.e., Pj is the last partition in the disk) and if W^^i can be inserted at the end of Pj without 

violating W^pis new deadline, then create a new partition of Pj and insert W^ni into it, othenwise keep W^nj in its 

current location in Pj. 

[0084] The second option is to update the deadline of write requests that are in the disk queue, but do not migrate 
25 the write requests backwards in the disk queue, i.e., leave them in their current locations in the disk queue. In other 
words, the new relax deadline will only effect the positioning of the new arriving write requests, but not the ones already 
existing in the queue. This option can be achieved by traversing the disk queue, locating the write requests in the 
queue, and updating the deadlines. The advantage of this option is the reduced overhead induced with the task asso- 
ciated when the value of changes, as the write requests do not have to be relocated after changing their deadlines. 
30 Moreover, relaxing the deadlines of the write requests that already exist in the disk queue will allow more read requests 
to be scheduled ahead of these write requests, and hence provides better performance on the video server 
[0085] The last option which will be provided is to take no action, i.e. , do not update the deadlines of the write requests 
that already exist in the disk queue and do not change their location. In other words, the change will only effect the 
new arriving rate request. This option represents the least overhead induced by the system. 

35 

Traffic Smoothing of Write Requests 

[0086] As can be seen from the previous sections, the R^jj read requests are handled regularly, until a write request 

arrives. The write buffer pool is used to ensure that the burst effect of write requests is smooth and is transferred into 
40 a steady stream of requests of a fixed rate. Every effort is made to schedule write requests along with R^j read requests 
as long as it is possible to schedule such write requests without conflicting with any read requests. 
[0087] There are two situations that would result in having the write buffer pool completely fill. This happens when 
the system is unable to schedule enough write requests to be sen/ed in the disk queue. It may also happen when there 
is an error in estimating the arrival rate of write requests to the write buffer. If the arrival rate is under-estimated, then 
45 an over-relaxed deadline for the write requests is computed. This results in scheduling less write requests then needed, 
and hence the write buffer pool may get filled. 

[0088] When the write buffer pool becomes full, some space must be freed in the write buffer to accommodate the 
arrival of new write requests. In order to avoid a burst of writing pages from the buffer to the disk, hence losing many 
contiguous read requests (R^i requests), the following is performed. 
50 [0089] Based on the mixed ratio between editing and viewing, the frequency of execution of the traffic smoothing 
procedure is computed. Each time this procedure is executed, it forces some write requests in the disk queue to be 
fulfilled and hence freeing some pages in the write buffer. This assists in avoiding the case where a burst of write 
requests are flushed to disk when the write buffer gets full. The most critical performed measure here is how much 
traffic smoothing can enhance the distribution of the inter-arrival time of the event of losses of read requests. 

55 

Conclusion 

[0090] At least one advantage of the new read/write scheduling process is that it treats both read and write requests 
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in a homogenous manner in terms of deadlines and placing them, as much as possible, in scan order Furthermore, 
artificial, but practical deadlines for write requests are assigned which is a function of the amount of available write 
buffers and the arrival rate of the write requests. Therefore, all the requests (mixture of reads and writes) are serviced, 
whenever possible, by the disk and scan order. This directly leads to improve quality of service, or alternatively, better 
throughput for a given QOS. 

[0091] From the invention as described, it will be obvious that the same may be varied in many ways. Such variations 
are not to be regarded as a departure from the spirit and scope of the invention, and all such modifications as would 
be obvious to one skilled in the art or intended to be included within the scope of the following claims. 
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A ppendix A 

Pseudocode for Inserting W„„ Write Requests 
Detennine which partition of disk queue to insert new write request into 
Traverse queue partitions (either front-to-back or 
back-to-front order) and attempt to insert new write 
request into scan order as follows: 

Attempt to insert new write request into partition farthest 
from disk server (P^^); 

If deadline violated then attempt to insert into partition 
next closer to disk server (Pf^ j), keep attempting to insert 
at still closer partitions (Pn-2^ ) ^^^i' deadline is not 

violated; 

If deadline cannot be satisfied in any partition (even Pq) 
then do the following: 

Place new write request at partition that is 
ahead in the disk queue or at the head of 
the queue if no such partition exists (this 
corresponds to Case 5 below); 
Insert new write request into partition in appropriate scan order; 
Insert write request in its scan order in the current partition 
Evaluate possible resulting cases: 

Case 1 : the deadline of none of tlie pending read and 
write requests (including new write request) is violated 
by this insertion. 
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Case 2: the deadline of the new write request will not be 
violated if it is inserted in scan order, but upon insertion, 
the deadline of some other R^^ read rcqucst{s) will be 
violated. 

Case 3: the deadline of the new write request will not be 
violated if it is inserted in scan order, but upon insertion, 
the deadline of some other R^j read requesl(s) will be 
violated. 

Case 4: the deadline of the new write request will not be 
violated if it is inserted in scan order, but upon insertion, 
the deadline of some other write request(s) will be 
violated. 

Case 5: the deadline of the new write request will be 
violated. 

Handle the possible cases as follows: 

Case 1 : insert the new write request in scan order into 

the disk queue at partition determined above (Pj). 

Case 2: insert the violated R^^^ in scan order into a closer 

paaition (Pj_j) and insert new write request in the disk 

queue at partition determined above (Pj). 

Case 3: insert new wTite request in the disk queue at 

partition later than determined above (Pj.j) unless that will 

violate the new write request's deadline; if new write 

request's deadline is violated, try to locate a different R^^ 

15 
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to preempt, write the preempted I^,^ to a later partition; 
if doing so will save the violated read request Rj^^, 
otherwise the violated read request R^^j^ is lost. 
Case 4: revise system parameters to expand size of Write 
Buffer Pool. 

Case 5: place new write request at partition that is ahead 
in the disk queue or at the head of the queue if no such 
partition exists. 

A ppendix B 

Pseudocode for Inserting and Processing R^j Read Requests 

Determine which partition of disk queue to insert new read request into: 
Traverse queue partitions (either front-to-back or back-to-front order and attempt to 
insert new read request into scan order as follows: 

Attempt to insert new read request into partition farthest 

from disk server (P^^); 

If deadline violated then attempt to insert into partition 
next closer to disk server (P,i_i), keep attempting to insert 
at still closer partitions (Pn_2, Pn-3- ') deadline is not 
violated; 

If deadline cannot be satisfied in any partition 
(even Pq) then do the following: 

Search for any R„„ read request that can be moved from 

its location to another location to save the new read 
request; 
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If a R„„ request is identified that can be moved, 
move this R^^ request and proceed with inserting 
the new read request in the proper scan order; 
If a Rj^jj request cannot be found, discard the 
new read request as it is considered lost; 
Process the new read Request; 

Verify that the deadline of any of the other read or write requests in the 
identified queue is not violated before inserting the new read request into scan 
order; 

If no deadline is violated, insert the new read request in its scan order 
in the current partition; 

If a deadline is violated, determine if it is possible to place the new 
read request in the next partition (in the case of a front-to-back scan) 
or previous partition (in the case of a back-to-front scan) or if any 
other R^^ request may be pre-empted; 

If the new read request or any other Rj^j^ request may be pre-empted, 
insert the request(s) into their proper positions; 
If the new read request or any other R^^^ request cannot be inserted 
elsewhere, discard the new request as it is considered lost; 
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Appendix C 
Pseudocode for Inserting R^^ Read Requests 

Determine which partition of disk queue to insert new read request: 

Traverse queue partitions (either front-to-back or back-to-front order) 
and identify the partition that the new read request may be inserted as follows: 
Identify the partition (P|.) that the deadline of the new 
read request is not violated but would be violated in the 
next partition (Pfc+i); 
Traverse queue partitions (either front-to-back or back-to-front order) and 
determine the earliest partition that the new read request may be inserted 
without violating the deadlines of any R^j and Wj^,^ as follows; 
let the current partition be (Pj); 

if j k then insert the new read request into a partition (P^^) 
such that q is greater than or equal to k and inserting the new 
read request will not violate any W^^j^ requests and discard any 
Rji requests that have their deadlines violated due to the 
insertion of the new request into P^^; 

else if the new request can be inserted into Pj in scan 
order without causing any other requests in the disk 
queue to violate their deadlines, then insert the new 
request into Pj; 

else if inserting the new request into Pj in scan 
order will cause otlier requests in the disk queue 
to violate their deadlines, then determine if the 
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new read request may be inserted into the next 
partition (Pj + i). 



Claims 

15 1. A method of supporting the processing of simultaneous read requests and write requests of a storage device in 
the presence of real-time requirements that are associated with these requests, comprising the steps of: 

constructing a storage device data structure with a plurality of partitions that correspond to a plurality of seek 
paths, the storage device data structure storing both read requests and write requests; 
20 generating read request deadlines for the read requests that are based at least in part on a user-desired 

response time for handling the read requests; 

generating write request deadlines for the write requests that are based at least in part on the capacity of a 
write buffer that stores data associated with the write requests until the data is written to the storage device; and 
placing the read requests and the write requests within the storage device data structure based at least in part 
25 on the read request deadlines and write request deadlines, such that an optimal seek path is maintained for 

each of the plurality of partitions while minimizing violations of the read request deadlines and write request 
deadlines. 



2. The method of Claim 1 wherein the write request deadlines are based at least in part on an estimate of the time 
30 in which the write buffer will become full (K^). 

3. The method of Claim 2, further comprising the step of dynamically computing X^. 

4. The method of Claim 3, wherein the step of dynamically computing includes maintaining a running average of 
35 computed values of X^. 

5. The method of Claim 3, further comprising the step of regenerating the write request deadlines when has 
changed beyond a predetermined threshold. 

40 6. The method of Claim 5, further comprising the step of reorganizing the placement of the read and write requests 
based upon the regenerated write request deadlines. 

7. An article of manufacture for supporting the processing of simultaneous read requests and write requests of a 
storage device in the presence of real-time requirements that are associated with these requests, comprising: 

45 

a memory for storing data that is accessed by an application program being executed by a multimedia system; 
a data structure stored in said memory that contains data corresponding to both read requests and write 
requests of said storage device, said data structure including: 

a plurality of partitions that subdivide said data structure and that correspond to a plurality of seek paths of 
50 said storage device; 

a plurality of read request data stored in said data structure, said plurality of read request data having read 
request deadlines that are based at least in part on a user-desired response time for handling the read request; 
and 

a plurality of write request data stored in said data structure, said plurality of write request data having write 
55 request deadlines that are based at least in part on the capacity of a write buffer that stores data associated 

with the write requests until the data is written to the storage device, 

whereby said plurality of read request data and write request data are organized in said data structure such 
that an optimal seek path is maintained for each of said plurality of partitions while minimizing violations of 
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said read request deadlines and write request deadlines. 

8. The article of manufacture of Clainn 7, further comprising a storage device access scheduler that receives said 
read and write requests, calculates said read request deadlines, calculates said write request deadlines, and places 

s each of said read and write requests within said data structure. 

9. The article of manufacture of Claim 8, wherein said storage device access scheduler includes a write request 
deadline generator that receives said write requests and calculates said write request deadlines. 

10 10. The article of manufacture of Claim 8, wherein said storage device access scheduler includes a read request 
deadline assignerthat receives said read requests and calculates said read request deadlines. 

11. The article of manufacture of Claim 9, wherein said storage device access scheduler includes a data storage 
organizer that places each of the read and write requests within the queue data structure such that an optimal 

15 seek path is maintained for each of the plurality of partitions while minimizing violations of the read and write 

requests deadlines. 

12. A storage device access scheduler for supporting video-on-demand and non-linear editing of a storage device in 
the presence of real-time requirements that are associated with the read requests and write requests of video-on- 

20 demand and non-linear editing, comprising: 

a memory having a storage device data structure with a plurality of partitions that correspond to a plurality of 
seek paths, the storage device data structure storing both read requests and write requests; 
a read request deadline assigner for generating read request deadlines for the read requests that are based 
25 at least in part on a user-desired response time for handling the read requests; 

a write request deadline assigner for generating write request deadlines for the write requests that are based 
at least in part on the capacity of a write buffer that stores data associated with the write requests until the 
data is written to the storage device; and 

a disk queue organizer for placing the read requests and the write requests within the storage device data 
30 structure based at least in part on the read request deadlines and write request deadlines, such that an optimal 

seek path is maintained for each of the plurality of partitions while minimizing violations of the read request 
deadlines and write request deadlines. 

13. The storage device access scheduler of Claim 12 wherein the write request deadlines are based at least in part 
35 on an estimate of the time in which the write buffer will become full (k^). 

14. The storage device access scheduler of Claim 13, wherein is dynamically computed. 

15. The storage device access scheduler of Claim 13; wherein said write request deadline assigner regenerates the 
40 write request deadlines when has changed beyond a predetermined threshold. 
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